Modeling Homogeneous Parallelism

ABSTRACT

A model of a process is created using novel “fan-out” and “fan-in” symbols. A fan-out symbol represents a point in the process flow where a variable number of homogeneous parallel outgoing threads are being split out from a single incoming thread. The fan-in symbol represents a point in the process flow where a variable number of parallel incoming threads with homogeneous output are combined into one or more outgoing threads.

BACKGROUND OF THE INVENTION

The present disclosure relates to the field of computers, andspecifically to process modeling.

BRIEF SUMMARY OF THE INVENTION

A model of a process is created using novel “fan-out” and “fan-in”symbols besides the customary symbols for decision, merge, fork, join,task, etc. The novel “fan-out” and “fan-in” symbols permit modelingprocess behavior that cannot be modeled using these customary symbols. Afan-out symbol represents a point in the process flow where a variablenumber of homogeneous parallel outgoing threads are being split out froma single incoming thread. The fan-in symbol represents a point in theprocess flow where a variable number of homogeneous parallel incomingthreads are combined into one or more outgoing threads.

The above as well as additional objectives, features, and advantages ofthe present invention will become apparent in the following detailedwritten description.

BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS

The invention itself, as well as a preferred mode of use, furtherobjects, and advantages thereof, will best be understood by reference tothe following detailed description of an illustrative embodiment whenread in conjunction with the accompanying drawings, wherein:

FIG. 1 depicts an exemplary computer in which the present invention maybe implemented;

FIG. 2 illustrates an exemplary process model that uses novel fan-outand fan-in symbols; and

FIG. 3 is a high-level flow-chart of exemplary steps taken to model aprocess using fan-in and fan-out symbols.

DETAILED DESCRIPTION OF THE INVENTION

As will be appreciated by one skilled in the art, the present inventionmay be embodied as a method, system, or computer program product.Accordingly, the present invention may take the form of an entirelyhardware embodiment, an entirely software embodiment (includingfirmware, resident software, micro-code, etc.) or an embodimentcombining software and hardware aspects that may all generally bereferred to herein as a “circuit,” “module” or “system.” Furthermore,the present invention may take the form of a computer program product ona computer-usable storage medium having computer-usable program codeembodied in the medium. In a preferred embodiment, the computer programproduct comprises a process editor and/or a process modeling tool. Suchtools can be used for a number of purposes with the present invention,including but not limited to process documentation, process simulationand process definition for defining a process for execution in a runtimeenvironment.

Any suitable computer usable or computer readable medium may beutilized. The computer-usable or computer-readable medium may be, forexample but not limited to, an electronic, magnetic, optical,electromagnetic, infrared, or semiconductor system, apparatus, device,or propagation medium. More specific examples (a non-exhaustive list) ofthe computer-readable medium would include the following: an electricalconnection having one or more wires, a portable computer diskette, ahard disk, a random access memory (RAM), a read-only memory (ROM), anerasable programmable read-only memory (EPROM or Flash memory), anoptical fiber, a portable compact disc read-only memory (CD-ROM), anoptical storage device, a transmission media such as those supportingthe Internet or an intranet, or a magnetic storage device. Note that thecomputer-usable or computer-readable medium could even be paper oranother suitable medium upon which the program is printed, as theprogram can be electronically captured, via, for instance, opticalscanning of the paper or other medium, then compiled, interpreted; orotherwise processed in a suitable manner, if necessary, and then storedin a computer memory. In the context of this document, a computer-usableor computer-readable medium may be any medium that can contain, store,communicate, propagate, or transport the program for use by or inconnection with the instruction execution system, apparatus, or device.The computer-usable medium may include a propagated data signal with thecomputer-usable program code embodied therewith, either in baseband oras part of a carrier wave. The computer usable program code may betransmitted using any appropriate medium, including but not limited tothe Internet, wireline, optical fiber cable, RF, etc.

Computer program code for carrying out operations of the presentinvention may be written in an object oriented programming language suchas Java, Smalltalk, C++ or the like. However, the computer program codefor carrying out operations of the present invention may also be writtenin conventional procedural programming languages, such as the “C”programming language or similar programming languages. The program codemay execute entirely on the user's computer, partly on the user'scomputer, as a stand-alone software package, partly on the user'scomputer and partly on a remote computer or entirely on the remotecomputer or server. In the latter scenario, the remote computer may beconnected to the user's computer through a local area network (LAN) or awide area network (WAN), or the connection may be made to an externalcomputer (for example, through the Internet using an Internet ServiceProvider).

The present invention is described below with reference to flowchartillustrations and/or block diagrams of methods, apparatuses (systems)and computer program products according to embodiments of the invention.It will be understood that each block of the flowchart illustrationsand/or block diagrams, and combinations of blocks in the flowchartillustrations and/or block diagrams, can be implemented by computerprogram instructions. These computer program instructions may beprovided to a processor of a general purpose computer, special purposecomputer, or other programmable data processing apparatus to produce amachine, such that the instructions, which execute via the processor ofthe computer or other programmable data processing apparatus, createmeans for implementing the functions/acts specified in the flowchartand/or block diagram block or blocks.

These computer program instructions may also be stored in acomputer-readable memory that can direct a computer or otherprogrammable data processing apparatus to function in a particularmanner, such that the instructions stored in the computer-readablememory produce an article of manufacture including instruction meanswhich implement the function/act specified in the flowchart and/or blockdiagram block or blocks.

The computer program instructions may also be loaded onto a computer orother programmable data processing apparatus to cause a series ofoperational steps to be performed on the computer or other programmableapparatus to produce a computer implemented process such that theinstructions which execute on the computer or other programmableapparatus provide steps for implementing the functions/acts specified inthe flowchart and/or block diagram block or blocks.

With reference now to FIG. 1, there is depicted a block diagram of anexemplary computer 100, with which the present invention may beutilized. Computer 100 includes a processor unit 104 that is coupled toa system bus 106. A video adapter 108, which drives/supports a display110, is also coupled to system bus 106. System bus 106 is coupled via abus bridge 112 to an Input/Output (I/O) bus 114. An I/O interface 116 iscoupled to I/O bus 114. I/O interface 116 affords communication withvarious I/O devices, including a keyboard 118, a mouse 120, a CompactDisk-Read Only Memory (CD-ROM) drive 122, and a flash memory drive 126.The format of the ports connected to I/O interface 116 may be any knownto those skilled in the art of computer architecture, including but notlimited to Universal Serial Bus (USB) ports.

Computer 100 is able to communicate with a server 150 via a network 128using a network interface 130, which is coupled to system bus 106.Network 128 may be an external network such as the Internet, or aninternal network such as an Ethernet or a Virtual Private Network (VPN).Server 150 may be architecturally configured in the manner depicted forcomputer 100.

A hard drive interface 132 is also coupled to system bus 106. Hard driveinterface 132 interfaces with a hard drive 134. In one embodiment, harddrive 134 populates a system memory 136, which is also coupled to systembus 106. System memory 136 is defined as a lowest level of volatilememory in computer 100. This volatile memory may include additionalhigher levels of volatile memory (not shown), including, but not limitedto, cache memory, registers, and buffers. Code that populates systemmemory 136 includes an operating system (OS) 138 and applicationprograms 144.

OS 138 includes a shell 140, for providing transparent user access toresources such as application programs 144. Generally, shell 140 (as itis called in UNIX®) is a program that provides an interpreter and aninterface between the user and the operating system. Shell 140 providesa system prompt, interprets commands entered by keyboard 118, mouse 120,or other user input media, and sends the interpreted command(s) to theappropriate lower levels of the operating system (e.g., kernel 142) forprocessing. As depicted, OS 138 also includes kernel 142, which includeslower levels of functionality for OS 138. Kernel 142 provides essentialservices required by other parts of OS 138 and application programs 144.The services provided by kernel 142 include memory management, processand task management, disk management, and I/O device management.

Application programs 144 include a browser 146. Browser 146 includesprogram modules and instructions enabling a World Wide Web (WWW) client(i.e., computer 100) to send and receive network messages to theInternet. Application programs 144 also include a HomogeneousParallelism Modeling Program (HPMP) 148, which is preferably a processeditor (and/or a process modeling tool) that includes software code forperforming the methods described below in FIG. 2-3.

Computer 100 may utilize HyperText Transfer Protocol (HTTP) messaging toenable communication with server 150. In one embodiment, computer 100 isable to download HPMP 148 from service provider server 150, preferablyin an “on demand” basis. In another embodiment, service provider server150 performs all of the functions associated with the present invention(including execution of HPMP 148), thus freeing computer 100 from usingits own resources.

The hardware elements depicted in computer 100 are not intended to beexhaustive, but rather represent and/or highlight certain componentsthat may be utilized to practice the present invention. For instance,computer 100 may include alternate memory storage devices such asmagnetic cassettes, Digital Versatile Disks (DVDs), Bernoullicartridges, and the like. These and other variations are intended to bewithin the spirit and scope of the present invention.

With reference now to FIG. 2, an exemplary process model 200, which usesnovel fan-in and fan-out symbols, is presented. Process model 200depicts an exemplary process in which an order is issued, filled,shipped and billed. The depicted process takes place across four processcomponents: customer 202, foodCorporation 204, foodDivision 206, andfoodTransport 208. In the example shown in FIG. 2, each of the processcomponents are disparate. This disparity may be due to at least one ofthe process components being executed by a different individual orenterprise, computer, software program, in a different physicallocation, enterprise division, etc. compared to the other processcomponents. Thus, as will be discussed further below, since thesplitting and re-joining of execution threads happens in differentenvironments, it is not possible to model this process using prior arttechniques such as a customary “for-all” construct. In addition, thefan-out/fan-in points are not fork/join points, since fork/join pointssplit a process into a fixed number of parallel threads at a fork (thenumber of thread is known at modeling time) and recombine this knownnumber of threads into one at a join. Note that in one embodiment, theterm “thread” is used below to describe software threads. In anotherembodiment, however, the term “thread” is understood to describe anycombination of human or automated tasks that execute part or all of abusiness process. Accordingly, the tasks of the process may bemanifested through written communication, verbal communication, serviceprotocols, etc.

The process model 200 begins with an order being issued(“issueOrder”—task 210). An order, which represents the initial threadof a new execution of the exemplary process, is sent from a customercomponent (customer 202) to a food corporation component(foodCorporation 204), where it starts an execution of task“validateOrder” 212. After validation, the foodCorporation(foodCorporation 204) will split the order thread into a variable numberof threads (one per division) that will participate in the fulfillment.The spawning of multiple threads from a single order thread is modeledusing the fan-out symbol. The outbound flow from the fan-out symbol thusrepresents a variable number of threads for each inbound thread to thefan-out. In this exemplary process, each of the threads spawned at thispoint is represented by a division order. The multiple threads resultingfrom a fan-out execute the same kind of behavior (tasks, steps), whichis why this kind of parallelism is referred to as “homogeneous.” (Notethat parallel threads emerging from a prior art fork typically show adifferent behavior for each thread. Thus, the parallelism resulting fromthe execution of a prior art fork is also referred to as heterogeneousparallelism.)

Assume now, for exemplary purposes, that the “Order” contained lineitems for three types of food: 1) fruits/vegetables, 2) dairy productsand 3) meat. The first fan-out point 214 would then split the incomingthread carrying an “Order” artifact into three outgoing threads carrying“DivisionOrders”. The division orders would be addressed to thefruits/vegetables, dairy products, and meat processing divisions,respectively, and contain the order items that the target division isexpected to fill. Thus, the first (fruits/vegetables) division ordergoes to a fruits/vegetables food division (one of the instances of fooddivision 206), the dairy order goes to a dairy food division (anotherone of the instances of food division 206), and the meat order goes to ameat food division (a third instance of food division 206). Note thatthere is no forking of the threads followed by a local joining back ofthe threads, since the fanned-out threads are sent to differentlocales/divisions/processes/etc. In fact there is no requirement thatthe fanned-out threads ever be joined back into one thread, as would bethe case had this been modeled using a “for all” or “for each”. In a“for all” or “for each” process, a single unit of code takes inputs froman array to generate an output array. In the present model, however, thehomogeneous parallel threads are simply extracted in a stand-aloneexecutable form from each incoming thread and continue without anyguarantee that they will ever be rejoined.

Note that when the incoming thread is split up, different threads can goto different swim lanes shown in FIG. 2. When a thread enters a processcomponent (a “swim lane” such as that shown for customer 202,foodCorporation 204, foodDivision 206, foodTransport 208) and there aremultiple instances of the process participant (for example, foodDivision206) whose behavior this component represents, then addressing logic asthe thread enters the target component must decide which of theparticipants this thread is destined for. For example, a division ordermay carry an electronic address (URL, e-mail address, etc.) thatdesignates the target division 206.

In each division, a second fan-out point 216 breaks out each incomingthread. For example, assume that one of the threads (depicted) is forfruits/vegetables. This thread is split out into five threads: 1)lettuce, 2) tomatoes, 3) corn, 4) peaches and 5) bananas, one per lineitem in the division order. Each line item is filled (block218—“fulfillLineItem”), and is then sent to the food transport 208process component, where items are consolidated at a first fan-in point220. If we assume that the original order contained 5 fruit/vegetableand 18 dairy and 7 meat line items, a total of 5+18+7=30 threadsresulting from the one original order would arrive at the food transportcompany. Items are consolidated according to their destination, and allthreads for items having a common destination are grouped. Note that thegrouping of threads performed by the fan-in 220 does not reverse thesplitting performed by either fan-out 214 or fan-out 216. This abilityto join execution threads in a way that is not symmetric to theiroriginal spawning is another capability afforded by the presentinvention that is not afforded by a traditional “for-each” or “for-all.”A fan-in must have a criterion to decide when “all” incoming threadshave arrived, or when it is time to spawn an outbound thread thatconsolidates a number of incoming threads that have arrived up to thispoint. A grouping fan-in, as in this example where threads are groupedby shipping destination, has such criteria for each group of threads itcollects (there can also be common criteria, which apply to several orall groups). The completion criterion for the fan-in 220 could be thatall line items for a particular order that are destined for the sameshipping location have arrived (the logic of the fan-in could determinethis by looking up the order information in a database, using theoriginal order number that comes with each line item as a key).Alternatively, the fan-in 220 could react to an external trigger 223(timer, alert, etc.) and release groups of accumulated threads intooutgoing threads when that trigger 223 occurs. For example, the foodtransport company could have a policy to collect incoming fooddeliveries (line items) until 4 PM each day, at which point the fan-inreleases all deliveries that have arrived to that point, grouped bydestination, so that trucks can be loaded for an over-night transport.Each outbound thread from the fan-in 220 thus represents a group of lineitems with the same destination, which is indicated by the arraynotation (“LineItem[ ]”). If there are four destinations for the fooddeliveries, then the fan-in 220 would consolidate the 30 incomingthreads into 4 outgoing ones. The four outgoing threads may contain 5,10, 12 and 3 line items, respectively, where each group of items has thesame destination, but can contain a mix of fruit/vegetable, dairy, andmeat products. The four groups of items are then split by a thirdfan-out point 222, which divides each group into truck loads. If weassume that one truck is needed for both the first and fourth group, buttwo trucks for the second and the third, then a total of 6 truck loadswill result. The trucks are loaded (point 224) and the productsdelivered (point 226).

The customer then acknowledges receipt of the items in each truck loadthat arrives (block 228). The output of that step is an array of lineitem numbers, representing all items that a particular truck delivered.Those arrays are transferred back to the food corporation as an“acknowledgement of receipt” message. The food corporation consolidatesthem in a final fan-in whose grouping criterion is the order numbercarried by each “acknowledgement of receipt”, and whose completioncriterion is the arrival of all receipts for items in one original order(made possible since the food corporation retains copies of all originalorders in a database). After all acknowledgements of receipt (one pertruck) have been consolidated, by the fan-in point 230, a singleoutgoing thread is started to create an invoice (block232—“createInvoice”).

Note that a fan-in point may buffer inbound flows during an extendedperiod of time, while fan-out points instantly explode one inboundthread of execution. That is, a fan-in point may be designed such thatfan-in occurs only after necessary incoming threads have arrived, whilea fan-out preferably occurs immediately, since each thread being inputto the fan-out contains all needed information to create the resultingbatch of outgoing threads.

Note also that threads that are being combined by a fan-in need not comefrom an output of a fan-out. Thus, while the first fan-in 220 usedthreads from the second fan-out 216 in the example shown, alternativelythreads being input into any fan-in (including fan-in 220) may come fromany source (not shown), assuming that all threads being input into thefan-in are materialized as the same kind of message, item(s), ordocument(s).

Referring now to FIG. 3, a high-level flow-chart of steps taken to modela process using fan-out and/or fan-in point symbols is presented. Afterinitiator block 302, fan-out points are identified (block 304). In apreferred embodiment, fan-out points are defined as points in which asingle incoming thread is split out into a variable number ofhomogeneous outgoing threads that can be executed in parallel. Eachidentified fan-out point is then represented by a fan-out symbol in theprocess model (block 306), preferably as an apex-to-base triangle asshown in FIG. 2. Similarly, any fan-in points are identified (block308), in which a variable number of incoming threads are combined intoone or more outgoing threads. Each identified fan-in point isrepresented by a fan-in symbol in the process model (block 310),preferably as a base-to-apex triangle as shown in FIG. 2. The processmodel can then be used to implement a process that is described by themodel (block 312), which can then be executed in a (human and/orautomated) environment that understands the semantics of “fan-out” and“fan-in.” The steps end at terminator block 314.

Note that the flowchart and block diagrams in the Figures illustrate thearchitecture, functionality, and operation of possible implementationsof systems, methods and computer program products according to variousembodiments of the present invention. In this regard, each block in theflowchart or block diagrams may represent a module, segment, or portionof code, which comprises one or more executable instructions forimplementing the specified logical function(s). It should also be notedthat, in some alternative implementations, the functions noted in theblock may occur out of the order noted in the figures. For example, twoblocks shown in succession may, in fact, be executed substantiallyconcurrently, or the blocks may sometimes be executed in the reverseorder, depending upon the functionality involved. It will also be notedthat each block of the block diagrams and/or flowchart illustration, andcombinations of blocks in the block diagrams and/or flowchartillustration, can be implemented by special purpose hardware-basedsystems that perform the specified functions or acts, or combinations ofspecial purpose hardware and computer instructions.

The terminology used herein is for the purpose of describing particularembodiments only and is not intended to be limiting of the invention. Asused herein, the singular forms “a”, “an” and “the” are intended toinclude the plural forms as well, unless the context clearly indicatesotherwise. It will be further understood that the terms “comprises”and/or “comprising,” when used in this specification, specify thepresence of stated features, integers, steps, operations, elements,and/or components, but do not preclude the presence or addition of oneor more other features, integers, steps, operations, elements,components, and/or groups thereof.

The corresponding structures, materials, acts, and equivalents of allmeans or step plus function elements in the claims below are intended toinclude any structure, material, or act for performing the function incombination with other claimed elements as specifically claimed. Thedescription of the present invention has been presented for purposes ofillustration and description, but is not intended to be exhaustive orlimited to the invention in the form disclosed. Many modifications andvariations will be apparent to those of ordinary skill in the artwithout departing from the scope and spirit of the invention. Theembodiment was chosen and described in order to best explain theprinciples of the invention and the practical application, and to enableothers of ordinary skill in the art to understand the invention forvarious embodiments with various modifications as are suited to theparticular use contemplated.

Having thus described the invention of the present application in detailand by reference to preferred embodiments thereof, it will be apparentthat modifications and variations are possible without departing fromthe scope of the invention defined in the appended claims.

1. A method for modeling homogeneous parallelism in a process, themethod comprising: identifying a fan-out point in the process, whereinthe fan-out point occurs where the process splits a single incomingthread into a variable number of homogenous parallel outgoing threads,and wherein the homogeneous parallel threads are created in accordancewith a fan-out parameter that is part of the single incoming thread andis used to determine the variable number of homogeneous paralleloutgoing threads; representing the fan-out point with a fan-out symbolin a process model; identifying a fan-in point in the process, whereinthe fan-in point occurs where a variable number of incoming threads withhomogeneous output are recombined into a single outgoing thread, andwherein the fan-in point defines grouping criteria for incoming threadsand completion criteria for each group of thread, wherein the completioncriteria and external completion triggers determine when a group ofthreads being fanned-in is complete; and representing the fan-in pointwith a fan-in symbol in the process model.
 2. The method of claim 1,wherein a quantity of the homogeneous parallel threads produced at afan-out point is unknown when the process is initially modeled.
 3. Themethod of claim 1, wherein a thread, which is to be executed by at leastone of the disparate process components, is identified by a uniquethread identifier.
 4. The method of claim 3, wherein the unique threadidentifier is retained at each fan-out by copying the unique threadidentifier to each of corresponding outgoing threads produced by thefan-out, wherein an identification of a set of threads, which is createdat the fan-out point, enables re-joining of a same set of threads at alater stage in the process model.
 5. The method of claim 1, wherein anoperation of a fan-in point to recombine all incoming threads into asingle outgoing thread is initiated by an external trigger.
 6. Themethod of claim 1, wherein a thread combining action of the fan-in pointis initiated by a “completeness condition” that is evaluated each time anew thread arrives, and wherein the “completeness condition” becomestrue whenever a complete set of threads required to create an outboundthread has arrived at the fan-in point.
 7. The method of claim 1,wherein a fan-in point is configured with a grouping criterion, whereinthe grouping criterion is evaluated on each incoming thread to establishan output bucket for each incoming thread, and wherein threads in theoutput bucket are released into a single outgoing thread when thegrouping criterion for the bucket has become true.
 8. The method ofclaim 1, wherein the disparate process components are performed bydifferent divisions in an enterprise.
 9. The method of claim 1, whereinthe disparate process components are performed by different companies inan enterprise.
 10. The method of claim 1, wherein the disparate processcomponents are realized as computer software instructions that areexecuted by different computers.
 11. The method of claim 10, wherein thecompletion criteria is an external trigger.
 12. The method of claim 1,further comprising: associating an associated software with each elementrepresented in the process model; and executing the associated software.13. The method of claim 1, further comprising: associating a human taskwith each element represented in the process model; and executing thehuman task.
 14. A system comprising: a processor; a data bus coupled tothe processor; a memory coupled to the data bus; and a computer-usablemedium embodying computer program code, the computer program codecomprising instructions executable by the processor and configured formodeling homogeneous parallelism in a process by performing the stepsof: identifying a fan-out point in the process, wherein the fan-outpoint occurs where the process splits a single incoming thread into avariable number of homogenous parallel outgoing threads, and wherein thehomogeneous parallel threads are created in accordance with a fan-outparameter that is part of the single incoming thread and is used todetermine the variable number of homogeneous parallel outgoing threads;representing the fan-out point with a fan-out symbol in a process model;identifying a fan-in point in the process, wherein the fan-in pointoccurs where a variable number of incoming threads with homogeneousoutput are recombined into a single outgoing thread, and wherein thefan-in point defines grouping criteria for incoming threads andcompletion criteria for each group of thread, wherein the completioncriteria and external completion triggers determine when a group ofthreads being fanned-in is complete; and representing the fan-in pointwith a fan-in symbol in the process model.
 15. The system of claim 14,wherein a quantity of the homogeneous parallel threads is unknown whenthe process is initially modeled.
 16. A computer-readable medium encodedwith a computer program, the computer program comprising computerexecutable instructions configured for: identifying a fan-out point inthe process, wherein the fan-out point occurs where the process splits asingle incoming thread into a variable number of homogenous paralleloutgoing threads, and wherein the homogeneous parallel threads arecreated in accordance with a fan-out parameter that is part of thesingle incoming thread and is used to determine the variable number ofhomogeneous parallel outgoing threads; representing the fan-out pointwith a fan-out symbol in a process model; identifying a fan-in point inthe process, wherein the fan-in point occurs where a variable number ofincoming threads with homogeneous output are recombined into a singleoutgoing thread, and wherein the fan-in point defines grouping criteriafor incoming threads and completion criteria for each group of thread,wherein the completion criteria and external completion triggersdetermine when a group of threads being fanned-in is complete; andrepresenting the fan-in point with a fan-in symbol in the process model.17. The computer-readable medium of claim 16, wherein a quantity of thehomogeneous parallel threads produced at a fan-out point is unknown whenthe process is initially modeled.
 18. The computer-readable medium ofclaim 16, wherein a thread, which is to be executed by at least one ofthe disparate process components, is identified by a unique threadidentifier.
 19. The computer-readable medium of claim 16, wherein thecomputer-usable medium is a component of a remote server, and whereinthe computer executable instructions are deployable to a supervisorycomputer from the remote server.
 20. The computer-readable medium ofclaim 16, wherein the computer executable instructions are capable ofbeing provided by a service provider to a customer on an on-demandbasis.